fix: activate SPI DMA for STM32H7 targets - #1367
Conversation
spiInitBusDMA() (bus_spi.c) already guards STM32H7 alongside F4/F7, but USE_SPI_DMA_ENABLE_LATE was only defined for STM32F4/STM32F7 in common_fc_pre.h (PR emuflight#1348), so H7 targets never reached the fc_init.c call site. Adds the same define for the STM32H7 block, matching the existing F4/F7 pattern. No STM32H7 USE_GYRO_IMUF9001 target exists, so this doesn't interact with the SPI1-exclusion guard added by PR emuflight#1359. Closes emuflight#1353
📝 WalkthroughWalkthroughThe STM32H7 target configuration now enables ChangesSTM32H7 SPI DMA configuration
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/main/target/common_fc_pre.h`:
- Line 100: Keep USE_SPI_DMA_ENABLE_LATE disabled by default or make it
explicitly opt-in until STELLARH7DEV validation is complete; record successful
gyro, motor, flash, and reboot hardware tests before enabling it for all USE_SPI
builds.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f2c4f02e-10ed-4d45-99df-a5b2360d6b2a
📒 Files selected for processing (1)
src/main/target/common_fc_pre.h
📜 Review details
⏰ Context from checks skipped due to timeout. (12)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: build (targets-group-8)
- GitHub Check: build (targets-group-10)
- GitHub Check: build (targets-group-7)
- GitHub Check: build (targets-group-4)
- GitHub Check: build (targets-group-3)
- GitHub Check: build (targets-group-6)
- GitHub Check: build (targets-group-5)
- GitHub Check: build (targets-group-11)
- GitHub Check: build (targets-group-1)
- GitHub Check: build (targets-group-9)
- GitHub Check: build (targets-group-2)
AI Generated [pull-request]
Summary
Closes #1353.
spiInitBusDMA()(src/main/drivers/bus_spi.c) already guards#if (defined(STM32F4) || defined(STM32F7) || defined(STM32H7)) && defined(USE_SPI)— H7support exists in the function itself. PR #1348 only defined
USE_SPI_DMA_ENABLE_LATEforSTM32F4/STM32F7incommon_fc_pre.h; H7 targets never reached thefc_init.ccallsite (gated
#if defined(USE_SPI) && defined(USE_SPI_DMA_ENABLE_LATE)), sospiInitBusDMA()was dead code on every H7 target.
This PR adds the same define to the
STM32H7block, mirroring the existing F4/F7 pattern.One line, one file.
No
USE_GYRO_IMUF9001target is STM32H7-based (HELIOSPRING/STRIXF10/MODE2FLUX are allF4/F7), so this doesn't interact with the SPI1-exclusion guard PR #1359 added.
Tier classification
Tier 2 — behavioral change (DMA path activation), per this project's production-
readiness gates. All requirements verified on real STELLARH7DEV hardware — see below.
dmaconfirmsSPI_SDI/SDO 3active; blackbox
gyroADC/gyroUnfiltsane throughout a real hover flight)motor[0-3]full-range utilization (152–2047), no stuckvalues, during the same flight
Scope note: this physical board has 4 IMU footprints (
ICM-42688-P,ICM-45686,ICM-45605,ICM-40609-D, per the board schematic). EmuFlight only implementsICM-42688-Pon STELLARH7DEV (USE_GYRO_SPI_ICM42688P) — the other three have no EFdriver and no multi-IMU selection mechanism (
USE_IMU1/USE_IMU2is Betaflight-only,doesn't exist in EF). All verification above is scoped to
ICM-42688-Ponly.Verification done
make clean && CCACHE_DISABLE=1 make test: 42/42 unit test binaries pass, 0 fail.CCACHE_DISABLE=1 make STELLARH7DEV MATEKH743 KAKUTEH7: clean compile, zero warnings.spiInitBusDMAis placed at a real addressand cross-referenced from the LTRANS object — genuinely linked in under
-Wl,-gc-sections, not just present-but-eliminated.default-on, then withdrew it after re-tracing
bus_spi.c/bus_spi_ll.c/dma_stm32h7xx.c/the H7 linker scripts — confirmed H7's DTCM/cache DMA constraints arealready handled generically, same fallback-to-polling model as the accepted F4/F7
precedent. Full exchange: PR review thread starting at
fix: activate SPI DMA for STM32H7 targets #1367 (comment).
Real-hardware verification (STELLARH7DEV) — 2026-08-09
CLI
dma/status/tasks, master vs. this branch, same board/config:master(035fff1): zero SPI DMA anywhere (expected — no H7 call site existed yet).461bee6): addsDMA1 Stream4/5 = SPI_SDO/SDI 3(gyro, ICM42688P) andDMA1 Stream6/7 = SPI_SDO/SDI 4(flash, W25M02G) — every pre-existing row (MOTOR 1-4on
DMA1 Stream0-3,ADConDMA2 Stream1) unchanged. Zero collision.GYRO/PIDtiming: master avg 30µs/31.2% maxload vs. branch avg 29-31µs/30-35% maxloadacross multiple captures — no regression, consistent with DMA offloading transfer work.
3x flash + reboot power cycle: byte-identical
dmatable and consistentGYRO/PIDtiming across all 3 boots — no init-time race.
Hover-flight test: blackbox log confirmed on this exact firmware build (
461bee6,STELLARH7DEV), ~39s flight. 0
failsafePhasenon-IDLE rows across 63,965 samples; 1momentary
rxSignalReceivedblip (negligible — same pattern seen in PR #1348's own flighttest);
motor[0-3]full utilization, no stuck values;gyroUnfilt/gyroADCranges sanefor the maneuvers flown.
Test plan
make test— 42/42 passspiInitBusDMAgenuinely activated on STELLARH7DEV